Уже где-то год прошел с момента релиза версии 6.1 решения для виртуализации сетей виртуального и физического датацентра VMware NSX. Поэтому VMware давно уже было пора обновить продукт и согласовать его с последними версиями линейки продуктов для серверной и десктопной виртуализации. Как мы все давно ждали, на днях вышла обновленная версия VMware NSX 6.2, где появилась масса нужных новых возможностей.

Приведем здесь основные из них:

1. Поддержка последних версий платформ виртуализации.

VMware NSX 6.2 поддерживает как VMware vSphere 5.5, так и vSphere 6.0. Новые функции в плане сетевого взаимодействия и безопасности между двумя серверами vCenter поддерживаются только для vSphere 6.0.

2. Возможности Cross vCenter Network Virtualization.

В NSX 6.2 поддерживаются окружения, где логические коммутаторы, распределенные логические маршрутизаторы и распределенные сетевые экраны размещены таким образом, что их действие распространяется на объекты с разными vCenter. Официально эта возможность называется Cross-vCenter Network and Security.

Теперь политики фаервола или логических сетевых компонентов могут быть помечены как Universal, что означает, что настройки реплицируются между модулями NSX Manager и будут сохранены при миграции vMotion виртуальной машины на другой хост ESXi, который находится под управлением другого сервера vCenter.

3. Новые универсальные логические объекты сети.

• Universal Logical Switch (ULS) - возможность создания логических коммутаторов, которые объединяют несколько серверов vCenter. Это позволяет создать L2-домен сетевого взаимодействия для приложения в виртуальной машине, которое может "путешествовать" между датацентрами.
• Universal Distributed Logical Router (UDLR) - это логический распределенный роутер, осуществляющий маршрутизацию между объектами ULS, описанными выше. Этот маршрутизатор работает также и на базе географического размещения ВМ.
• Universal IP sets, MAC sets, security groups, services и service groups - все эти объекты поддерживают распределенные структуры с несколькими vCenter.

4. Поддержка VMware vCenter Server 6 с различными топологиями Platform Services Controller (PSC).

Если раньше NSX поддерживала только встроенные сервисы PSC (Platform Services Controller), то теперь поддерживаются различные распределенные топологии (об этом мы писали вот тут). Теперь полностью поддерживаются такие компоненты, как vCenter SSO, license service, lookup service, VMware Certificate Authority и прочее.

5. Поддержка L2 Bridging для Distributed Logical Router.

L2 bridging теперь может принимать участие в распределенной логической маршрутизации. Сеть VXLAN, к которой присоединен экземпляр бриджинга, используется для взаимосоединения Routing instance и Bridge instance.

6. Новый механизм обнаружения IP-адресов для виртуальных машин.

Ранее IP-адреса виртуальных машин обнаруживались по присутствию в них VMware Tools и добавлялись вручную. Теперь есть 2 новых способа добавления адресов: DHCP snooping и ARP snooping (причем присутствие VMware Tools необязательно).

7. Улучшения средств управления и решения проблем.

Тут появились следующие новые фичи:

• Central CLI - единый интерфейс командной строки для обычных и распределенных функций NSX.
• Traceflow troubleshooting tool - утилита, которая позволяет понять, возникла проблема в виртуальной или физической сети, за счет слежения за прохождением пакета через виртуальный и физический сетевой стек.
• Функции Flow monitoring и IPFix теперь можно включать отдельно (раньше можно было только вместе и это создавало много нагрузочного трафика, особенно в больших окружениях).
• Отчет в реальном времени о состоянии управляющих компонентов NSX: состояние связей между NSX Manager и агентом сетевого экрана, NSX Manager и консолью управления, между хостами ESXi и NSX Controller.

8. Улучшения LB Health Monitoring.

Теперь доступен гранулярный мониторинг состояния, который предоставляет информацию о произошедших сбоях, а также отслеживает информацию об изменении состояния компонентов NSX и связей между ними. Помимо этого, также предоставляется информация о возможных причинах сбоев.

9. Поддержка диапазона портов для LB.

Теперь для приложений, которым нужно использовать диапазон портов для LB, есть возможность задать этот диапазон.

10. Прочие улучшения.

• Возможность сохранять тэг VLAN при коммуникациях VXLAN.
• Просмотр активного узла в HA-паре.
• Увеличено максимальное число виртуальных IP-адресов.
• Поддержка vRealize Orchestrator Plug-in for NSX 1.0.2.
• Возможность включения/отключения uRPF check для отдельного интерфейса.
• Улучшения Load balancer health monitoring.
• Прочие улучшения, полный список которых приведен вот тут.

Скачать VMware NSX 6.2 можно по этой ссылке. Документация по продукту доступна вот тут.

Кроме того, VMware NSX версии 6.2 поддерживает инфраструктуру виртуальных ПК VMware Horizon View версии 6.0.1 и боее поздних (другие продукты вы тоже можете добавить в VMware Product Interoperability Matrix):

Про поддержку VMware Horizon View есть также небольшое видео:

Как вы знаете, с 30 августа по 3 сентября в Сан-Франциско пройдет самая большая и полезная конференция по виртуализации VMware VMworld 2015. Компания StarWind Software, как производитель решения номер 1 для создания программных отказоустойчивых хранилищ Virtual SAN под виртуальные машины, среди прочих примет в ней участие.

Приходите на стенд StarWind под номером #442, чтобы узнать о комплексном решении StarWind Hyper-Converged Platform, включающем в себя следующие компоненты для построения инфраструктуры небольшого предприятия или филиала:

• Серверы Dell
• Гипервизор VMware vSphere
• Решение для резервного копирования и репликации Veeam Backup & Replication
• Решение для построения отказоустойчивого программного кластера хранилищ StarWind Virtual SAN

Ну и наиболее активный и сообразительный из вас получит PlayStation 4!

Приходите на стенд StarWind, обещаем много интересного!

На днях компания Microsoft объявила о бесплатной доступности виртуальных машин с новой версией гостевой ОС Windows 10 в виде готовых виртуальных модулей (Virtual Appliances) для самых популярных платформ виртуализации: VMware vSphere / Workstation, Microsoft Hyper-V, Oracle VirtualBox и Parallels Desktop. На хостовой ОС Windows можно использовать платформы Workstation, Hyper-V или VirtualBox, для Mac OS можно использовать VMware Fusion, Parallels Desktop или VirtualBox, а на Linux можно запустить машину только на VirtualBox.

В ближайшее время появятся также машины в других форматах (например, QEMU), так как Microsoft автоматизировала процесс создания этих виртуальных модулей. Сделано все это для того, чтобы пользователи как можно быстрее втягивались в использование браузера Microsoft Edge и новой Windows 10. Кстати, он называется IE11, когда машинку добавляешь в консоль:

Виртуальные машины распространяются как zip-архив размером около 5 Гбайт, где находятся соответствующие файлы ВМ в форматах виртуальных модулей (для VMware это OVA). Сама машина настроена на устаревание через 90 дней после первого включения, соответственно рассматривать ее нужно только как среду для тестирования, а не как производственную машину (так как после устаревания данные будут недоступны). Microsoft рекомендует сразу после загрузки создать снапшот ВМ, чтобы всегда можно было откатиться на чистую систему.

Microsoft также сообщает, что данные виртуальные машины вышли с багом: в настройках иногда появляется сообщение "Connect to the Internet to activate", которое нужно проигнорировать - на функциональность оно не влияет.

Скачать готовые виртуальные машины с Windows 10 можно по этой ссылке.

Интересную утилиту, которая будет полезна всем администраторам Citrix XenDesktop, анонсировал Andrew Morgan. Citrix Director Notification Service - это сервис, который следит за состоянием компонентов инфраструктуры XenDesktop и оповещает администраторов по почте, когда что-то сломалось.

У компании Citrix есть специальный продукт для этих целей - Citrix Director, но он показывает состояние компонентов XenDesktop только в консоли, которую нужно постоянно запускать и обновлять. А Director Notification Service позволит вам это делать автоматически и в реальном времени.

Утилита проверяет состояние следующих компонентов инфраструктуры виртуальных ПК:

• Citrix Licensing
• Соединение к базе данных
• Службу Broker Service
• Основные службы XenDesktop (Core Services)
• Соединение с гипервизором (это может быть как XenServer, так и VMware vSphere)

Вот так это выглядит:

В случае появления неисправности в XenDesktop, Citrix Director Notification Service посылает письмо администратору с подробным описанием типа неисправности. Когда работа компонента восстанавливается, также посылается письмо.

Интересно, что через Director Notification Service можно ловить алерты от гипервизора. Вот, например, такое ловится от VMware vSphere (у хоста осталось мало памяти):

После установки утилиты нужно запустить Configuration Utility:

Там настраиваются параметры SMTP-сервера для отправки писем, а также параметры доступа к Citrix Desktop Delivery Controller (DDC). Кроме того, доступны настройки и самого сервиса (например, частота опроса компонентов):

Не забывайте нажать кнопки "Test", чтобы проверить настройки.

Ну и после развертывания утилиты надо запустить Director Notification Service. Его можно установить на Edge-компьютер в периметре датацентра, а можно прямо на DDC.

Эта версия утилиты была протестирована на Citrix XenDesktop 7.6, но должна работать и на более ранних версиях платформы.

Прочитать инструкции по установке продукта можно вот тут, а скачать Citrix Director Notification Service можно по этой ссылке.

Не успели администраторы VMware vSphere нарадоваться полезному веб-клиенту для серверов ESXi, как на сайте проекта VMware Labs появилась следующая интересная штуковина - VNC Server and VNC Client.

Эта штука представляет собой сервер и клиент в виде standalone-приложений для доступа к консоли виртуальных машин в продуктах VMware vSphere и VMware Workstation. Имплементация VNC-протокола уже есть в этих продуктах, за счет нее и работает так называемая MKS-консоль в толстом и тонком клиентах vSphere.

VNC-протокол передает сессию на VNC-клиент к удаленному десктопу, на котором установлен VNC-сервер. Утилита работает из командной строки и не имеет UI, но работает аналогично подобным VNC-пакетам:

Надо отметить, что соединения по протоколу VNC не являются защищенными, поэтому рекомендуется их использовать в VPN-сети или в туннеле SSH.

Возможности VNC-клиента и сервера:

• Оптимизированы для каналов с ограниченной пропускной способностью
• На клиенте консоль сделана в стиле клиентов VMware
• Пользователям доступны дополнительные расширения при соединении с виртуальной машиной VMware напрямую или с VMware VNC Server

VNC Server может быть развернут на Windows, Linux или Mac OS X. VNC Client работает из под Windows и Linux. Скачать VNC Server and VNC Client можно по этой ссылке.

Некоторое время назад мы публиковали несколько заметок о поддержке платформой VMware vSphere открытой архитектуры OpenStack (тут и тут). Ну а недавно VMware собрала все свои видео о поддержке OpenStack в единый плейлист, чтобы удобно было получить информацию о различных аспектах использования этой архитектуры:

С помощью VMware Integrated OpenStack вы можете имплементировать поддержку OpenStack в существующей инсталляции VMware vSphere. Делает это путем развертывания виртуального модуля Integrated OpenStack Manager vApp в VMware vCenter. Затем вы указываете кластер управления и вычсилительные кластеры, пулы хранилищ, настраиваете сетевое взаимодействие и добавляете необходимые ресурсы в консоль управления.

Из этих видео вы узнаете как:

• Проводить анализ логов
• Выполнять окрестрацию операций
• Проводить управление емкостями ресурсов и анализ затрат
• Обслуживать и администрировать ресурсы
• Обновлять программные компоненты
• Осуществлять мониторинг ресурсов и решение проблем
• Добавлять проекты (Projects) и пользователей
• Управлять группами безопасности
• Добавлять образы новых систем
• Добавлять хранилища
• Добавлять сети
• Добавлять инстансы
• Непосредственно развертывать инфраструктуру OpenStack
• Развертывать OpenStack vApp

На сайте проекта VMware Labs появилась наиполезнейшая вещь - ESXi Embedded Host Client. Это написанный полностью на JS и HTML 5 веб-клиент для сервера VMware ESXi, который все так долго ждали:

Этот клиент работает только для управления хостами VMware ESXi (его нельзя использовать для управления сервером vCenter). Он позволяет производить следующие операции с хост-сервером и виртуальными машинами:

• Операции с состоянием ВМ (включение, выключение, приостановка и прочее)
• Создание новой виртуальной машины с нуля или развертывание из виртуального модуля OVF/OVA (для OVA поддержка пока ограничена)
• Настройка сервисов времени NTP на хосте
• Отображение информации о машинах, их конфигурациях, событиях, задачах, нотификациях и алертах
• Получение доступа к консоли виртуальной машины
• Настройка сетевого окружения на хосте ESXi
• Настройка расширенных параметров (advanced settings)
• Конфигурация сервисов, работающих на хосте

В принципе, список включает все необходимые операции для хоста без vCenter, которые могут потребоваться в повседневной работе.

Для установки Embedded Host Client просто загрузите VIB-пакет приложения во временную папку и установите его командой:

# esxcli software vib install -v /tmp/esxui.vib

Далее можно без перезагрузки хоста ESXi заходить по следующему адресу и управлять сервером:

https://<адрес ESXi или IP>/ui/

Если у вас ESXi 5.5 или ESXi 6.0, полученный обновлением с версии 5.5, то вам нужно заглянуть сюда. Скачать ESXi Embedded Host Client можно по этой ссылке.

Если вы администратор VMware vSphere со стажем, то наверняка попадали в такую ситуацию: по какой-то причине отключается сервер VMware vCenter (он может работать, но не отвечать на подключения), а с ним вместе недоступна и его база (на том же хосте или на отдельном) - и вам нужно искать хост ESXi с этими ВМ, чтобы поднять всю виртуальную инфраструктуру. А хостов ESXi в кластере у вас может быть несколько десятков.

Можно, конечно, сделать правило DRS для vCenter, чтобы он не перемещался по хостам, но в случае срабатывания аварийного восстановления VMware HA, сервер vCenter вполне может поменять хост, так как HA забивает на правила DRS.

В этом случае может оказаться полезным интерфейс PowerCLI, который позволит найти нужную ВМ по ее имени. Но сначала вам нужно разрешить множественные соединения к нескольким хостам. Делается это следующей командой:

Set-PowerCLIConfiguration -DefaultVIServerMode Multiple -Scope Session

Теперь можно соединиться со всеми серверами одновременно и найти там vCenter. Делается это следующей командой:

connect-viserver @("esx1","esx2","esx3") -user root -password password

Это, конечно, покатит только если у вас на всех хостах ESXi везде одинаковый пароль root. Но если они там разные, то нужно будет для каждого сервера исполнить соответствующую команду.

Далее просто ищем нужную виртуальную машину по ее имени:

(get-vm vCenter01).vmhost
(get-vm SQL01).vmhost

В выводе этих команд будут хосты ESXi, на которых они зарегистрированы. Остается только открыть к ним консоль через vSphere Client и включить эти машины.

Каждый администратор VMware vSphere рано или поздно сталкивается с тем, что хост VMware ESXi выпадает в "Pink Screen of Death" (PSOD - розовый экран смерти):

Причина этого - как правило, аппаратные проблемы сервера (барахлящее оборудование, битые блоки памяти, проблемы с драйверами, в том числе виртуальных устройств, и т.п.). В этом случае полезно погуглить ошибку, но сначала нужно получить дамп ядра (core dump), где сохраняются подробности о причине PSOD.

В VMware vSphere Web Client в представлении Hosts and Clusters нажимаем правой кнопкой на сервере vCenter, далее в контекстном меню выбираем пункт "Export System Logs...":

Далее выбираем интересующий нас хост VMware ESXi:

Затем отчекиваем все галки, кроме CrashDumps:

После экспорта файла открываете его в текстовом редакторе и ищете строчку "@bluescreen":

Ниже вы увидите подробности о произошедшей ошибке:

В данном случае мы видим, что имеет место проблема с драйвером виртуального сетевого адаптера (vNIC) E1000. Можно заменить его на VMXNET3 (как описано в KB 2059053), и проблема уйдет. Ну и прочие подобные ошибки можно гуглить, по PSOD ESXi уже есть много информации на форумах.

Многие из вас в курсе, что на сайте проетка VMware Labs есть расширения PowerCLI Extensions (о них мы писали вот тут), позволяющие получить доступ к командлетам PowerCLI/PowerShell, которые еще не выпущены в релиз и доступны только в экспериментальном режиме.

На днях PowerCLI Extensions были обновлены, оттуда убрали командлеты относящиеся к VSAN, так как они были включены в релизную версию PowerCLI 6.0 R1. Но самое интересное, что в PowerCLI Extensions добавили экспериментальные командлеты функций Instant Clone. На самом деле, это фича VM Fork или Project Fargo, о которой мы писали вот тут.

Суть технологии VMFork такова, что "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory), что и родительская ВМ. При этом дочерняя ВМ в шаренную память писать не может, а для записи собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ.

Вот эти командлеты в обновленных PowerCLI Extensions:

В рамках процесса создания мгновенного клона дочерняя ВМ появляется на свет без изначальной загрузки. В процессе работы VMFork происходит кратковременное "подвешивание" родительской ВМ (quiescence) с помощью технологии "fast suspend resume" (FSR), после чего дочерняя ВМ "отцепляется" от родительской, приобретая свою сетевую идентификацию (IP-адрес, маску и т.п.). При этом ВМ шарят общие ресурсы на чтение и имеют свои уникальные области на запись - это очень удешевляет стоимость ресурсов в перерасчете на одну ВМ на хосте.

Сначала сетевые параметры клона задаются следующим массивом:

$configSettings = @{
'ipaddress' = "10.134.14.75";
'netmask' = '255.255.255.0';
'gateway' = '10.134.14.253';
}

Затем мы делаем Instant Clone машины следующей командой:

$childForkVm = New-InstantCloneVM -ParentVM $parentforkVm -Name "2012ChildClone$_" -ConfigParams $configSettings

Это позволяет мгновенно получить свою новую, независимую виртуальную машину, которая имеет свою сетевую идентификацию и диски. Так как в машине стоят VMware Tools, то можно проверить новые настройки с помощью вызова VMware Tools RPCTool:

• "%programfiles%\vmware\vmware tools\rpctool" "info-get guestinfo.fork.ipaddress"
• "%programfiles%\vmware\vmware tools\rpctool" "info-get guestinfo.fork.netmask"
• "%programfiles%\vmware\vmware tools\rpctool" "info-get guestinfo.fork.gateway"

На видео ниже проверяются настройки ВМ, которую собираются клонировать, затем вызываются PowerCLI-команды, чтобы получить 9 мгновенных клонов (у автора видео это заняло 15 секунд):

Потенциально это очень полезная технология, особенно для сред разработки и тестирования. Скачать VMware PowerCLI Extensions с функциями VMware Instant Clone можно по этой ссылке.

У многих администраторов VMware vSphere зачастую возникает необходимость понизить версию виртуального аппаратного обеспечения (hardware version) виртуальной машины. Это может понадобиться в следующих случаях (и не только):

• когда толстый клиент vSphere Client не поддерживает всех функций новой версии Virtual Hardware
• новая версия железа не поддерживается старыми хостами VMware ESXi, которые вы еще не успели обновить
• если вы пользуетесь услугами внешнего провайдера IaaS (аренда виртуальных машин), то у провайдера может оказаться не самая последняя версия платформы, и при миграции в его облако обновленное Virtual Hardware не будет поддерживаться

Так или иначе, сделать даунгрейд виртуального железа можно, и это достаточно просто. Если апгрейд делается из контекстного меню виртуальной машины в vSphere Client:

То даунгрейд можно сделать одним из трех способов:

1. Перед апгрейдом виртуального обеспечения нужно сделать снапшот виртуальной машины. При откате к нему произойдет и откат к предыдущей версии виртуального железа.
2. Можно использовать VMware Converter Standalone для V2V-миграции, при которой можно выбрать нужную версию Virtual Hardware.
3. Можно создать новую виртуальную машину с нужной версией железа (например, на старом хосте ESXi), к которой прицепить диск от исходной ВМ.

Многие из вас знают о решении StarWind Virtual SAN, предназначенном для создания отказоустойчивых хранилищ. Но не все в курсе, что у StarWind есть виртуальный модуль Virtual SAN OVF (ссылка на его загрузку высылается по почте), который представляет собой шаблон виртуальной машины в формате OVF готовый к развертыванию на платформе VMware vSphere.

Недавно компания StarWind выпустила документ Virtual SAN OVF Deployment Guide, в котором описана процедура развертывания данного виртуального модуля.

Поскольку Microsoft на уровне лицензии запрещает распространение таких виртуальных модулей с гостевой ОС Windows в формате виртуальных дисков VMDK, придется сделать несколько дополнительных операций по развертыванию, а именно:

1. Запустить StarWind V2V Converter.
2. Преобразовать VHDX-диски в формат VMDK.
3. Поместить VMDK и OVF в одну папку.
4. Развернуть OVF на сервере VMware ESXi.
5. Заполнить поля IP-адреса для включения машины в виртуальную сеть.
6. Подождать окончания процесса создания и конфигурации виртуальной машины.

Больше подробностей о виртуальном модуле StarWind Virtual SAN OVF вы найдете в документе.

Компания Код Безопасности, производитель решений номер 1 для защиты виртуальных сред, выпустила обновление продукта vGate R2 (версия 2.8). Эта версия прошла инспекционный контроль в ФСТЭК России (с подтверждением выданных ранее сертификатов соответствия от 28.03.2011 № 2308 и от 12.07.2011 № 2383) и доступна для загрузки и покупки.
Таги: vGate, Update, Security, VMware, vSphere, Microsoft, Hyper-V, Security Code

Как начать с работать с кластерами хранилищ - документ VMware Virtual SAN 6.0 Proof of Concept Guide.

Не так давно компания VMware выпустила интересный документ "VMware Virtual SAN 6.0 Proof of Concept Guide", который позволяет представить себе в голове план пошаговой имплементации решения VSAN во всех его аспектах (хосты ESXi, настройка сети, тестирование решения, производительность, средства управления и т.п.).

Процесс, описанный в документе, представляет собой развертывание кластера Virtual SAN в изолированной среде для целей тестирования, чтобы обкатать решение в небольшой инфраструктуре и потом уже отправить его в производственную среду.

Основные разделы документа освещают следующие темы:

• Подготовительные работы
• Настройка сетевого взаимодействия
• Включение функций кластера хранилищ
• Функциональность платформы VMware vSphere при операциях в кластере VSAN
• Масштабирование кластера VSAN на несколько узлов
• Политики хранилищ
• Мониторинг состояния кластера
• Тестирование производительности
• Симуляция аппаратных отказов и тестирование поведения кластера
• Управление кластером Virtual SAN

Сам документ содержит 170 страниц и представляет собой ну очень детальное руководство по развертыванию кластера Virtual SAN и его тестированию. Причитав его, вы поймете множество интересных технических особенностей, касающихся принципов работы решения.

Скачать "VMware Virtual SAN 6.0 Proof of Concept Guide" можно по этой ссылке.

Многие из вас знают, что в период с 12 по 15 октября, традиционно в Барселоне, пройдет очередной VMworld Europe 2015.

Недавно на соответствующем ресурсе компания VMware опубликовала список сессий и спикеров предстоящей конференции:

Из интересного (взято у Дункана Эппинга, вбивайте номер сессии в поиск):

• HBC5008 – vCloud Air Disaster Recovery Technical Deep Dive
• INF5060 – What’s New in vSphere?
• STO5877 – What’s New in Virtual SAN 6.1
• EUC5762 – End-to-end Security with AirWatch, VMware NSX and Intelligent Networking
• INF4528 – vCenter Server Appliance (VCSA) Best Practices & Tips/Tricks – William Lam
• INF5211 – Automating Everything VMware with PowerCLI – Deep Dive – Alan Renouf & Luc Dekens
• STO4949 – Extreme Performance Series: Virtual SAN Performance Deep-Dive – Lenin Singaravelu & Sankaran Sivathanu
• NET4989 – The Future of Network Virtualization with VMware NSX – Bruce Davie
• STO6228 – Monitoring and Troubleshooting Virtual SAN, Current and Future – Christian Dickmann & Cormac Hogan
• CNA6649-S – Build and run Cloud-Native Apps in your Software-Defined Data Center – Kit Colbert & Aaron Sweemer & Jared Rosoff
• VAPP4639 – Best Practices for Performance Tuning of Virtualized Telco and NFV Applications on vSphere ESXi – Bhavesh Davda & Jin Heo
• STO4649 – Virtual Volumes Technical Deep Dive – Ken Werneburg & Patrick Dirks
• NET5612 – NSX for vSphere Logical Load Balacing Deep Dive – Dimitri Desmidt & Uday Masurekar
• INF5701 – Extreme Performance Series: vSphere Compute & Memory – Fei Guo & Seong Beom Kim
• CTO6455 – Future Meets Present: Insights from VMware’s Field CTOs – Joe Baguley & Chris Wolf & Paul Strong
• INF5306 – DRS Advancements in vSphere 6, Advanced Concepts, and Future Directions – Naveen Nagaraj
• STO5336 – VMware Virtual SAN – Architecture Deep Dive – Christos Karamanolis & Rawlinson Rivera
• INF4529 – VMware Certificate Management for Mere Mortals – Adam Eckerle & Ryan Johnson
• STO6287-SPO – Instant Application Recovery and DevOps Infrastructure for VMware Environments – A Technical Deep Dive – Chris Wahl & Arvind Nithrakashyap
• INF4535 – 5 Functions of Software Defined Availability – Frank Denneman & Duncan Epping
• STO5333 – Building a Stretched Cluster with Virtual SAN – Rawlinson Rivera & Duncan Epping
• SDDC5027 – VCDX Unwrapped – Everything You Wanted to Know About VCDX – Panel
• STO4650-QT – Five Common Customer Use Cases for Virtual SAN – Lee Dilworth & Duncan Epping

Ну и кому интересно - небольшое видео о том, зачем ехать на VMworld в Барсу:

Те из вас, кто занимается обслуживанием инфраструктуры VMware vSphere, знают, что многие ее компоненты строятся на базе виртуальных модулей (Virtual Appliances) - готовых к развертыванию виртуальных машин, реализующих необходимый сервис. Например, к таким модулям относится основной сервер управления VMware vCenter Server Appliance (vCSA). Эти модули обладают множеством преимуществ, таких как простота развертывания, миграции или обслуживания, но имеют и недостаток - иногда происходит недостаточная частота обновлений или имеет место сложность организации их накатывания.

Со второй частью этой проблемы раньше приходилось разбираться на уровне конкретного виртуального модуля. Вот, например, раздел апдейтов виртуального модуля VMware Infrastructure Navigator:

Как мы видим, здесь можно использовать онлайновый депозиторий по умолчанию, а можно указать Repository URL, по которому данный виртуальный модуль будет проверять наличие обновлений, не выходя в интернет.

Вот таким хранилищем репозиториев и раздачи обновлений в виде ISO-модулей стал продукт VAMI Update Repository Appliance (VURA), доступный на сайте проекта VMware Labs:

Вы можете развернуть готовый модуль VURA, подцепить туда VMDK-диски большой емкости, наполнить их ISO-шками и раздавать в качестве апдейтов по указанному URL (по умолчанию это https://[your appliance IP]:5480).

Очень удобная и полезная штука - без нее просто не обойтись в большой инфраструктуре, где действуют особые требования к безопасности, касающиеся обновлений и доступа хостов в интернет.

Загрузить VAMI Update Repository Appliance в виде готового модуля можно по этой ссылке. Кромо того, для желающих есть исходные коды модуля VURA - может быть что-то со временем удастся сделать лучше.

Недавно компания VMware выпустила очень интересный документ "What’s New in VMware vSphere 6 - Performance", в котором рассказывается о том, какие улучшения были сделаны в новой версии vSphere 6.0, касающиеся различных аспектов производительности платформы (вычислительные ресурсы, хранилища и сети).

Документ выпущен отделом технического маркетинга VMware, и в нем приведены вполне конкретные сведения об увеличении производительности компонентов vSphere.

Например, вот сводная картинка улучшения производительности vCenter (версия 6.0 против 5.5) при тяжелых нагрузках на Microsoft SQL Server 2012 в зависимости от числа объектов, которые находятся под управлением сервиса (размер Inventory). Данные приведены в количестве операций в минуту. Результаты впечатляют:

Улучшения кластеров отказоустойчивых хранилищ VMware Virtual SAN (результаты по конфигурации All-Flash еще не обработаны):

С точки зрения производительности виртуальных сетевых адаптеров VMXNET 3, платформа vSphere 6.0 научилась выжимать из них более 35 гигабит в секунду при работе с физическими адаптерами 40 GbE:

Ну и в целом в документе есть еще много чего интересного - скачивайте.

Недавно компания StarWind Software, известная своим продуктом номер 1 - Virtual SAN для создания отказоустойчивых кластеров хранилищ, обновила свое замечательное средство для преобразования виртуальных машин между платформами виртуализации - StarWind V2V Converter.

Напомним, что StarWind V2V Converter умеет преобразовывать виртуальные машины между форматами VHD/VHDX, VMDK и нативным форматом продуктов StarWind - IMG. Для большей надежности, перед конверсией StarWind V2V Converter создает резервную копию виртуальной машины. Сейчас это лучшее бесплатное средство двусторонней конверсии между Microsoft Hyper-V и VMware vSphere.

После начала конверсии V2V Converter активирует Windows Repair Mode. Это позволяет гостевой ОС на новой платформе виртуализации автоматически обнаружить виртуальные устройства и установить необходимые драйверы.

Новые возможности последней версии StarWind V2V Converter V8 Build 162:

• Поддержка образов виртуальных машин Red Hat KVM и QCOW2 (QEMU).
• Поддержка сжатого формата VMDK ("Stream-optimized"), который используется для виртуальных модулей VMware OVF.
• Автоматический апдейт виртуального аппаратного обеспечения при изменении формата дисков виртуальной машины.

Скачать обновленный StarWind V2V Converter V8 можно по этой ссылке.

На одном из блогов о виртуализации на платформе VMware появилась интересная утилита VLANidentificator, предоставляющая информацию о принадлежности всех ваших виртуальных машин к портгруппам виртуальных коммутаторов и их VLAN ID:

Вы просто вводите стартовый IP-адрес и подсеть для сканирования, а скрипт пробегается по всем хостам VMware ESXi и vCenter, после чего все данные помещаются в сводную таблицу, в которой вы можете проверить, что нужные машины находятся в нужных VLAN, а также посмотреть на каких хостах ESXi они сейчас размещены. Для показа полной информации о машине, в том числе IP-адреса, нужно чтобы в ВМ были установлены VMware Tools.

Утилитка требует PowerShell 3 и более поздней версии и протестирована для работы с VMware vSphere 5.0, поэтому с шестой версией вполне может не работать. Поддерживаются также и распределенные виртуальные коммутаторы VMware Distributed Switch (vDS).

Исполняемый файл VLANidentificator можно скачать по этой ссылке. Ну а исходный код можно скачать вот тут.

Как многие из вас знают, в состав платформы виртуализации VMware vSphere 6.0 входит виртуальный модуль VMware vCenter Server Appliance (vCSA) 6.0, который реализует все необходимые сервисы управления виртуальной инфраструктурой в виде уже готовой виртуальной машины на базе Linux.

По умолчанию в данном модуле настроено устаревание пароля в 90 дней, и если в течение этого времени он не был сменен, он устареет и не будет работать. То есть, через три месяца вы увидите вот такую картинку:

Unable to authenticate user. Please try again.

В этом случае вам нужно либо сбросить пароль vCenter Server Appliance и установить новый, либо (если вы помните старый пароль , но он устарел) разлочить аккаунт.

Делается это вот каким образом:

1. Используем какой-нибудь Linux LiveCD (например, KNOPPIX).

Подключаем ISO-шку к виртуальной машине с vCSA и загружаемся с нее в Shell:

Затем повышаем привилегии командой:

# su -

2. Монтируем файловую систему vCSA с помощью команды:

# mount /dev/sda3 /mnt

3. Создаем резервную копию файла с паролем рута и открываем его для редактирования:

# cd /mnt/etc
# cp shadow shadow.bak
# vi /mnt/etc/shadow

Видим определение пароля root:

4. Если вы помните пароль, а он просто устарел:

В этом случае просто удаляем букву x (выделена желтым) и цифру 1 (также желтая - останется два двоеточия). Нажмите клавишу <i>, чтобы перейти в режим редактирования. После того, как вы внесете нужные изменения, нажмите <esc> и потом напишите ZZ, после чего нажмите ввод, чтобы сохранить изменения.

После перезагрузки vCSA старый пароль root будет работать.

5. Если вы не помните пароль:

Надо заменить его хэш. Сначала смотрим, что стоит в начале строчки. У вас, скорее всего, будет там $6$, что означает, что это хэш, сгенерированный по алгоритму SHA512. От правого доллара конструкции $6$ и до следующего доллара в этой строчке идет так называемая "соль" - это значение вам надо записать на бумажке или сфотать (доллары в него не входят).

Далее генерируем новый пароль, используя записанную соль, следующей командой:

# mkpasswd -m sha-512 <новый пароль> <соль>

Потом получившийся пароль просто вставляем в файл /etc/shadow, который вы только что открывали. Вставляем его от правого доллара, ограничивающего соль, до первого двоеточия. Тут плоховато видно, но суть понятна, куда вставлять этот пароль:

После перезагрузки vCSA вы можете логиниться в него с новым паролем.

Интересный сервис по продвижению решения Virtual SAN предлагает компания VMware через своих партнеров. Поскольку сам продукт стоит очень дорого, и мало кого можно на него подписать вот так вот сразу, VMware предлагает воспользоваться услугой VSAN Assessment. Она бесплатна, может быть оказана любым партнером VMware и позволяет получить необходимую конфигурацию аппаратного обеспечения для консолидации существующих виртуальных машин в отказоустойчивых кластерах Virtual SAN (напомним, что емкость там формируется из емкости локальных дисков серверов, являющихся узлами кластеров VSAN).

Суть сервиса такова: партнер регистрирует в закрытой партнерской секции новое обследование инфраструктуры (VSAN Assessment), после чего отправляет инвайт на него потенциальному заказчику. Он, в свою очередь, скачивает готовый виртуальный модуль (Collector Appliance), настраивает его и держит запущенным в течение, по крайней мере, одной недели (минимально).

В течение этого времени происходит сбор профилей рабочей нагрузки по вводу-выводу, на основании чего можно уже нарисовать необходимые ресурсы кластера хранилищ, выбрать нужную модель сервера для узла VSAN и определить требуемое число таких узлов.

Сначала анализируется виртуальная инфраструктура VMware vSphere на площадке клиента:

Затем выводятся рекомендуемые к консолидации в кластере хранилищ виртуальные машины. Также показывается совместимость с типом кластера Virtual SAN (All-flash или гибридная модель, где данные размещаются на магнитных накопителях):

Затем мы видим требуемые ресурсы как для одного узла, так и для всего кластера Virtual SAN, а также видим, какой именно сервер и с какими аппаратными характеристиками имеется в виду (производителя сервера можно выбрать, само собой):

Ну и для того, чтобы заказчика отвлечь от высокой входной цены продукта Virtual SAN, используется метод убеждения по снижению совокупной стоимости владения (TCO - total cost of ownership) при внедрении решения VMware VSAN:

Ну и прямо расписывают вам экономию по годам:

Ну то есть, если вы все же решили потестировать технологию VMware Virtual SAN, обратитесь к своему поставщику - он заведет вам VSAN Assessment и вы сами посмотрите, какие железки рекомендуется использовать именно под ваши нагрузки по вводу-выводу для размещения виртуальных машин.

Есть такая штука в сфере ИБ - Security banner. Это когда при логине в какую-нибудь консоль вы выводите пользователю сообщение о характере информации и системы, к которой он пытается получить доступ, и предупреждаете о возможной ответственности за несанкционированный доступ. Вряд ли это много кого остановит, но все же с ним лучше, чем без него.

Вот способ сделать security banner для VMware ESXi. В VMware vSphere он бывает двух видов:

1. Login banner

Это текст, который показывается после ввода имени пользователя, но до ввода пароля:

Чтобы его поменять нужно залогиниться на хост VMware ESXi и с помощью редактора vi или nano отредактировать следующий файл:

# vi /etc/issue

Нажмите клавишу <i>, чтобы перейти в режим редактирования. После того, как вы внесете нужные изменения, нажмите <esc> и потом напишите ZZ, после чего нажмите ввод, чтобы сохранить изменения. Затем перезагрузите демон SSH следующей командой:

# /etc/init.d/SSH restart

2. Баннер MOTD.

Это баннер, который показывают пользователю после успешного логина по SSH. Чтобы задать его (по умолчанию он пустой), нужно отредактировать следующий файл через vi:

# vi /etc/motd

Также можно не лазить на хост VMware ESXi, а открыть vSphere Web Client, перейти в Manage->Settings и в разделе Advanced System Settings поискать по строчке "etc.". Там будет 2 параметра:

• Config.Etc.issue - это текст для security banner
• Config.Etc.motd - текст для баннера motd

То же самое можно сделать и в толстом клиенте vSphere Client:

Наши постоянные читатели помнят, что еще в 2009 году компания VMware анонсировала Project Onyx, предназначенный для записи действий пользователя в клиенте vSphere и их перекладывания на язык сценариев PowerShell. Также какое-то время назад на сайте проекта VMware Labs появилась утилита Onyx, которая проксировала команды от vSphere Client к серверу vCenter и записывала их как PowerCLI-скрипт (сейчас ее страница переехала вот сюда).

Ну а на днях компания VMware выпустила техническое превью Onyx for the Web Client, который уже позволяет начать запись действий пользователя и получить готовый сценарий прямо в веб-клиенте vSphere.

После установки Onyx for the Web Client появится иконка утилиты в домашнем меню веб-клиента:

Далее просто нажимаем кнопку записи (Start), после чего выполняем нужные нам действия в Web Client:

И получаем на выходе готовый сценарий для исполнения того же самого действия через PowerCLI:

Полученный сценарий можно сохранить:

Классная штука и просто находка для тех, кто хочет все автоматизировать в своей виртуальной инфраструктуре. Скачать Onyx for the Web Client можно по этой ссылке. Инструкции по установке находятся здесь. Поставить его можно как на vCenter Server Appliance, так и на vCenter Server для Windows.

Время от времени у пользователей VMware vSphere возникает ошибка, связанная с тем, что виртуальный диск VMDK виртуальной машины оказывается залоченным (то есть эксклюзивно используемым процессом VMX одного из хостов ESXi). В этом случае виртуальная машина не отвечает на попытки включить ее или переместить на другой хост-сервер средствами VMware vMotion. При этом процесс vmx вполне может быть запущен не на том хосте ESXi, на котором машина отображается в VMware vSphere Client или Web Client. Такое может случиться при падении хоста ESXi, массовом отключении питания или неполадках в сети SAN, а также и в некоторых других случаях.

Например, может быть вот такое сообщение об ошибке при включении машины:

Could not power on VM: Lock was not free

Для решения проблемы вам нужно найти хост ESXi, который исполняет vmx-процесс машины, и убить ВМ, которая не отвечает. После этого можно будет использовать VMDK-файл этой машины, а также включить ее, если она не работает.

Делается это следующим образом:

1. Находим хост, исполняющий vmx-процесс виртуальной машины с залоченным VMDK.

Для этого заходим по SSH на один из серверов ESXi (эта процедура работает для версий vSphere 5.5 P05 и 6.0, а также более поздних) и переходим в папку /bin:

#cd /bin

С помощью утилиты vmfsfilelockinfo ищем владельца лока нужного VMDK-файла:

~ # vmfsfilelockinfo -p /vmfs/volumes/iscsi-lefthand-2/VM1/vm1.vmdk -v 192.168.1.10 -u administrator@vsphere.local

Здесь vm1.vmdk - наш залоченный виртуальный диск, а 192.168.1.10 - IP-адрес сервера VMware vCenter. Вам потребуется ввести пароль его администратора.

Вывод будет примерно таким:

vmfsflelockinfo Version 1.0
Looking for lock owners on "VM1_1-000001-delta.vmdk"
"VM1_1-000001-delta.vmdk" is locked in Exclusive mode by host having mac address ['00:50:56:03:3e:f1']
Trying to make use of Fault Domain Manager
----------------------------------------------------------------------
Found 0 ESX hosts using Fault Domain Manager.
----------------------------------------------------------------------
Could not get information from Fault domain manager
Connecting to 192.168.1.10 with user administrator@vsphere.local
Password: xXxXxXxXxXx
----------------------------------------------------------------------
Found 3 ESX hosts from Virtual Center Server.
----------------------------------------------------------------------
Searching on Host 192.168.1.178
Searching on Host 192.168.1.179
Searching on Host 192.168.1.180
MAC Address : 00:50:56:03:3e:f1

Host owning the lock on the vmdk is 192.168.1.180, lockMode : Exclusive

Total time taken : 0.27 seconds.

Из вывода можно понять 2 важные вещи:

• MAC-адрес хоста, залочившего VMDK
• IP-адрес хоста, залочившего VMDK
• Тип лока - Exclusive

Кстати, лок может быть нескольких типов:

• mode 0 - нет лока
• mode 1 - эксклюзивный лок (vmx-процесс машины существует и использует VMDK-диск)
• mode 2 - лок только для чтения (например, для основного диска, в случае если у него есть снапшоты)
• mode 3 - лок для одновременной записи с нескольких хостов (например, для кластеров MSCS или ВМ, защищенных технологией VMware Fault Tolerance).

Более подробно об этом написано в KB 2110152.

2. Точно определяем хост, машина которого держит VMDK.

Если IP-адрес показан - хост определен. Если, мало ли, по какой-то причине его нет, можно ориентироваться на MAC-адрес. Выяснить его можно следующей командой на хосте ESXi:

# vim-cmd hostsvc/net/info | grep "mac ="

3. Обнаруживаем процесс VMX, который держит VMDK.

Выполняем на найденном ESXi команду:

# lsof | egrep 'Cartel|vm1.vmdk'

Получаем что-то вроде этого:

Cartel | World name | Type | fd | Description
36202 vmx FILE 80 /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/VM1/vm1.vmdk

Мы нашли Cartel ID нужного процесса VMX (36202). Теперь выполняем команду, чтобы найти ее World ID:

# esxcli vm process list

Получаем такой вывод:

Alternate_VM27
World ID: 36205
Process ID: 0
VMX Cartel ID: 36202
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a9 dc 9f bf
Display Name: Alternate_VM27
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM27/Alternate_VM27.vmx


Alternate_VM20
World ID: 36207
Process ID: 0
VMX Cartel ID: 36206
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a5 dc 94 5f
Display Name: Alternate_VM20
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM20/Alternate_VM20.vmx
...

Видим, что World ID нашей машины - 36205.

4. Убиваем VMX-процесс, залочивший VMDK.

Ну и убиваем зависший процесс VMX следующей командой:

# esxcli vm process kill --type force --world-id <ID>

После этого с машиной и ее диском можно делать уже что требуется.

Также для более ранних версий VMware vSphere посмотрите нашу статью вот здесь.

Это гостевой пост нашего партнера - компании ИТ-ГРАД. Давно прошли времена, когда бронирование отеля за рубежом было чем-то невероятным и отдавалось на откуп турагентствам. Никого не удивить и специализированными сервис-каталогами, где можно в разумные сроки выбрать себе временное пристанище на чужбине, почитать отзывы и оформить резерв. Сейчас таких агрегаторов достаточно, но не все они предлагают поддержку туристов на русском языке и полную прозрачность в отношении цен. Пять лет назад мы решили исправить эти недочеты и сделать свой сервис бронирования. Так появился Hotels.ru.

Совсем недавно компания StarWind Software, производитель средства номер 1 для создания отказоустойчивых программных хранилищ под виртуальные машины VMware и Microsoft - Virtual SAN, выпустила интересный документ по его бесплатному изданию - "StarWind Virtual SAN Free Getting Started".

Напомним, что полностью бесплатный продукт StarWind Virtual SAN Free позволяет превратить два новых или имеющихся у вас сервера в отказоустойчивый кластер хранения (с полностью дублированными зеркалированными узлами), который может служить для:

• размещения виртуальных машин Microsoft Hyper-V (NFS/SMB3)
• размещения виртуальных машин VMware vSphere (NFS)
• размещения баз данных MS SQL Server (SMB3)
• создания отказоустойчивого файлового сервера (SMB3/NFS)

Кстати, StarWind Virtual SAN Free - единственное решение, которое позволяет создавать HA-кластер из двух узлов неограниченной емкости абсолютно бесплатно. Более подробно об отличиях бесплатной и коммерческой версий продукта можно почитать вот в этом документе.

Если вы администратор платформы виртуализации VMware vSphere, то, наверное, часто замечали, что в некоторых случаях при операциях с виртуальными машинами и ее дисками происходит "подмораживание" ВМ (или "stun", он же "quiescence"). В этот момент виртуальная машина ничего не может делать - она недоступна для взаимодействия (в консоли и по сети), а также перестает на небольшое время производить операции ввода-вывода. То есть, ее исполнение ставится на паузу на уровне инструкций, а на уровне ввода-вывода совершаются только операции, касающиеся выполняемой задачи (например, закрытие прежнего VMDK-диска и переключение операций чтения-записи на новый диск при операциях со снапшотами).

Cormac Hogan написал на эту тему интересный пост. Stun виртуальной машины нужен, как правило, для того, чтобы сделать ее на время изолированной от окружающего мира для выполнения значимых дисковых операций, например, консолидация снапшотов. Это может занимать несколько секунд (и даже десятков), но часто это происходит на время около секунды и даже меньше.

Когда может возникать stun виртуальной машины? Есть несколько таких ситуаций.

1. Во время операции "suspend" (постановка ВМ на паузу). Тут происходит такое подмораживание, чтобы скинуть память ВМ на диск, после чего перевести ее в приостановленное состояние.

2. В момент создания снапшота. Об этом написано выше - нужно закрыть старый диск и начать писать в новый. На время этой операции логично, что приостанавливается ввод-вывод.

3. Консолидация снапшотов (удаление всех). Здесь тоже нужно "склеить" все VMDK-диски (предварительно закрыв) и начать работать с основным диском ВМ. А вот удаление снапшота в цепочке stun не вызывает, так как не затрагивает VMDK, в который сейчас непосредственно идет запись.

4. Горячая миграция vMotion. Сначала память передается от одной машины к целевой ВМ без подмораживания, но затем происходит такой же stun, как и при операции suspend, с тем только отличием, что маленький остаток памяти (минимальная дельта) передается не на диск, а по сети. После этого происходит операция resume уже на целевом хосте. Пользователь этого переключения, как правило, не замечает, так как время этого переключения очень жестко контролируется и чаще всего не достигает 1 секунды. Если память гостевой ОС будет меняться очень быстро, то vMotion может затянуться именно во время этого переключения (нужно передать последнюю дельту).

5. Горячая миграция хранилищ Storage vMotion. Здесь stun случается аж дважды: сначала vSphere должна поставить Mirror Driver, который будет реплицировать в синхронном режиме операции ввода-вывода на целевое хранилище. При постановке этого драйвера происходит кратковременный stun (нужно также закрыть диски). Но и при переключении работы ВМ на второе хранилище происходит stun, так как нужно удалить mirror driver, а значит снова переоткрыть диски уже на целевом хранилище.

В современных версиях vSphere работа со снапшотами была оптимизирована, поэтому подмораживания виртуальной машины во время этих операций вы почти не заметите.

Продолжаем вас знакомить с решением vGate R2 от компании Код Безопасности, предназначенным для защиты виртуальной инфраструктуры Hyper-V от несанкционированного доступа, а также для ее безопасной настройки средствами политик.

Скоро компания Код Безопасности представит публичный коммерческий релиз решения vGate R2 версии 2.8, а пока вы можете посмотреть ролик о том, как именно данный продукт обеспечивает защиту виртуальных сред VMware vSphere и Microsoft Hyper-V. Ролик достаточно технический и наглядный - из него реально можно узнать, как работает продукт и отдельные его функции:

В ролике раскрываются следующие темы, касающиеся решения vGate R2:

• Обзор архитектуры и функциональности продукта
• Рабочий процесс при взаимодействии администраторов виртуальной инфраструктуры и администраторов информационной безопасности
• Режимы работы (новое!) и централизованное управление
• Усиленная аутентификация администраторов
• Мандатный контроль доступа
• Контроль целостности
• Просмотр событий и работа с отчетами
• Поддержка распределенных инфраструктур (vCenter Linked Mode) и выгрузка конфигурации
• Шаблоны политик безопасности

Напомним, что продукт vGate имеет следующие сертификаты ФСТЭК:

• vGate R2. СВТ5/НДВ4, применяется для защиты АС до класса 1Г включительно и ИСПДн до УЗ1 включительно
• vGate-S R2. ТУ/НДВ2, применяется для защиты АС до класса 1Б включительно и ИСПДн до УЗ1 включительно

Скачать демо-версию vGate R2 2.8 можно по этой ссылке. Кстати, для рассчета стоимости решения можно использовать онлайн-калькулятор.

Давно мы не публиковали сравнений платформ виртуализации VMware vSphere и Microsoft Hyper-V, которые, как известно, лишены смысла (ибо они либо ангажированы, либо сравнивают мягкое с горячим, либо привязываются к конкретному варианту использования). Всем понятно, что VMware - это дорогая и мощная платформа для тех у кого есть деньги, а Microsoft - бюджетная платформа виртуализации серверов в небольших компаниях. И в ближайшие пару лет это вряд ли изменится.

Так вот, оказывается, одно из последних сравнений VMware vSphere 5.1 и Microsoft Hyper-V третьей версии (примерно то, что есть сейчас) мы публиковали аж в 2012 году. Но ведь не так давно компания VMware обновила свое сравнение, включив туда VMware vSphere 6.0, пытаясь, видимо, широко распространить эту презентацию до того, как Microsoft обновит свой Windows Server до платформы vNext (это будет в следующем году).

Ну а мы, без зазрения совести, публикуем здесь это сравнение.

Итак, основные параметры платформ (гипервизора). VMware действительно выигрывает по Enterprise-фичам, но все довольно спорно для SMB:

Обеспечение доступности и защита данных. Здесь VMware, конечно же, впереди. Но нужен ли такой уровень доступности (например, Fault Tolerance) для небольших компаний? Иногда да, но чаще выгоднее сэкономить.

Автоматизация и управление. Ну вот это все точно про крупную организацию:

Ну и традиционный булшит про стоимость владения (его как бы можно посчитать на калькуляторе VMware вот тут). Когда не могут оправдать высокую входную цену продукта - берутся, как правило, заливать про TCO. Типа автоматизация сэкономит вам кучу денег:

Как, помимо прочего, происходит экономия при виртуализации? Типа, говорят, становится меньше дел, и можно сократить "лишних" системных администраторов. На деле же геморроя становится больше, поэтому администратора приходится нанимать.

Многие из вас знают, что в скором времени компания Veeam выпустит обновленный пакет продуктов Veeam Availability Suite v9, который представляет собой лучшее средство для резервного копирования, репликации и управления виртуальной средой. В прошлой заметке мы писали о двух новых возможностях этого решения: интеграции с технологией EMC Storage Snapshots и Veeam Cloud Connect с функциями репликации.

Сегодня мы посмотрим, что еще нового будет в новой версии. Вторая запись в блоге Veeam рассказывает нам о том, что Veeam Availability Suite v9 будет поддерживать прямой доступ к хранилищам NAS/NFS при резервном копировании. Раньше пользователи NFS-массивов чувствовали себя несколько "обделенными" в возможностях, так как Veeam не поддерживал режим прямой интеграции с таким типом дисковым массивов, как это было для блочных хранилищ.

Теперь же появилась штука, называемая Direct NFS, позволяющая сделать резервную копию ВМ по протоколам NFS v3 и новому NFS 4.1 (его поддержка появилась только в vSphere 6.0), не задействуя хост-сервер для копирования данных:

Специальный клиент NFS (который появился еще в 8-й версии) при включении Direct NFS получает доступ к файлам виртуальных машин на томах, для которых можно делать резервное копирование и репликацию без участия VMware ESXi, что заметно повышает скорость операций.

Кроме этого, была улучшена поддержка дисковых массивов NetApp. В версии 9 к интеграции с NetApp добавилась поддержка резервного копирования из хранилищ SnapMirror и SnapVault. Теперь можно будет создавать аппаратные снимки (с учетом состояния приложений) с минимальным воздействием на виртуальную среду, реплицировать точки восстановления на резервный дисковый массив NetApp с применением техник SnapMirror или SnapVault, а уже оттуда выполнять бэкап виртуальных машин.

При этом процесс резервного копирования не отбирает производительность у основной СХД, ведь операции ввода-вывода происходят на резервном хранилище:

Ну и еще одна полезная штука в плане поддержки аппаратных снимков хранилищ от Veeam. Теперь появится фича Sandbox On-Demand, которая позволяет создать виртуальную лабораторию, запустив виртуальные машины напрямую из снапшотов томов уровня хранилищ. Такая лаборатория может быть использована как для проверки резервных копий на восстановляемость (сразу запускаем ВМ и смотрим, все ли в ней работает, после этого выключаем лабораторию, оставляя резервные копии неизменными), так и для быстрого клонирования наборов сервисов (создали несколько ВМ, после чего создали снапшот и запустили машины из него). То есть, можно сделать как бы снимок состояния многомашинного сервиса (например, БД-сервер приложений-клиент) и запустить его в изолированном окружении для тестов, ну или много чего еще можно придумать.

Veeam Availability Suite v9 ожидается к выпуску, скорее всего, в третьем квартале 2015 года. Следить за новостями по этому решению можно вот тут.